КТМ на смарт-стенде взаимодействия организаций: 10 тезисов и узловые точки

Роли

10 тезисов

1. У каждой стороны, каждого экземпляра и каждого агента — свой DID, у объектов — разные идентичности. did:ru:org — организации, did:ru:device — серийный экземпляр (не номенклатура), did:ru:agent — агенты. Паспорт, сертификат, договорные события — отдельные VC со своими id (слайд 48: «объекты и состояния сохраняют разные идентичности»). DID выводится из ключа — его нельзя присвоить или подменить.

2. Метка = DID экземпляра; сканирование = резолв DID + его VC. Скан открывает именно этот экземпляр: DID Document → VC паспорта → VC сертификата и его текущий статус (слайд 41). Сканирование ничего не «принимает» само по себе — это вход проверки.

3. Паспорт и сертификат — подписанные VC разных издателей. Паспорт выпускает «Взлёт» своим ключом (серийный ID, номенклатура, ссылка на сертификат серии), сертификат — «Русский регистр» (область, номер, срок, статус). Подписи DID-операций и VC закрывают нюанс постановки «did&vc пока не подписаны»; неподписанное в режиме required не принимается, правка в базе обнаруживается.

4. Криптографическое подтверждение и сертификат соответствия — разные функции (стр. 112–113). Подпись доказывает, кто и что выпустил; действующий сертификат доказывает соответствие продукции. verify показывает их раздельно: checks.proof и checks.status/time.

5. Приёмка — решение уполномоченного человека, оформленное подписью и передачей владения. Три проверки (сертификат относится к паспорту; прибор соответствует заказу; физический осмотр — человек, с доказательством) → контролёр ОЙЛТИМ подписывает VC приёмки, ОЙЛТИМ своей подписью принимает владение DID прибора (двухшаговая передача: изготовитель вписывает покупателя в controller, покупатель ставит себя owner). Это и есть «Владелец подтверждает получение» из постановки. Брак → VC осмотра с доказательством (хэш фото), изолятор и возврат — отдельные события, не «успех» приёмки.

6. Изменение статуса сертификата адресуется затронутым паспортам и сигналит обеим сторонам. Отзыв или изменение подписывает только издатель («Русский регистр»), с заданной областью; КТМ находит паспорта, ссылающиеся на этот сертификат в этой области, их DID и текущих владельцев и рассылает сигнал покупателю и изготовителю (слайд 43, шаг 4–5 постановки). Автоматически на всю историю не переносится.

7. Агент действует в выданной роли и узкой рамке. Мандат организации (AgentMandateCredential) задаёт разрешённые маршруты API КТМ, инструменты/MCP, собеседников и модель; вход в КТМ — подписью ключа DID агента, каждое действие сверяется с мандатом (/v1/agents/authorize). Это прямой аналог «адаптер ограничивает инструменты агента» и «доступ агента: выданная роль и внутренняя рамка» (слайды 50, 53).

8. Наличие инструмента или инженерный PASS не создают полномочия (стр. 101, 114). Самопрезентация агента (runtime: модель, веса, seed, инструкции) доверяется только при совпадении с мандатом владельца; сменил конфигурацию без нового мандата — доступ закрыт. Решения, требующие компетенции (приёмка, отзыв, предписание), подписывает человек своей ЭП (УКЭП/ГОСТ — через PKI-сервис).

9. Запрос, запись и деловой результат подтверждаются раздельно (слайды 46, 52). В КТМ это разные наблюдаемые состояния: принята подписанная операция (версия DID / id VC) → записана в реестр HLF (статус якорения pending/anchored, tx id) → деловое событие (приёмка, возврат, сигнал). Неверная форма даёт отказ с причиной и повтор того же случая (422 с указанием поля).

10. Результат работы агента — подписанный и объяснимый след. Вывод агента (AnalysisCredential) подписан его ключом и ссылается на входы: распоряжение Росстандарта, паспорта, сертификаты, ответы агентов других сторон. Межагентный обмен — только между DID, которые есть в мандатах друг друга, по каналу на ключах keyAgreement. Выход участника стенда — «связанный след случая и объяснение решений с трёх позиций» (слайд 47) — в КТМ получается из графа подписанных VC и истории DID.

Узловые точки участия КТМ

A. «Сертификат → паспорт → метка → приёмка» (постановка 0–3; стенд: слайды 41–42, ведомость стр. 115)

1. «Русский регистр» выпускает VC сертификата серии (область, номер, срок) — подпись ключом из своего DID.

2. «Взлёт» (агент + человек) регистрирует did:ru:device экземпляра, выпускает VC паспорта со ссылкой на сертификат, метка BIMAR кодирует DID.

3. ОЙЛТИМ сканирует метку → КТМ отдаёт паспорт, проверенный статус сертификата, условия поставки по договору.

4. Три проверки → контролёр подписывает приёмку → ОЙЛТИМ принимает владение DID → КТМ фиксирует в HLF, уведомляет «Взлёт» и «Русский регистр» о новом владельце и условиях эксплуатации.

Признак завершения: связаны все три объекта (сертификат, паспорт, метка) и есть подписанные приёмка и смена владельца.

B. «Изменение статуса сертификата» (постановка 4–5; стенд: слайд 43, стр. 100)

1. «Русский регистр» своей подписью меняет статус / отзывает сертификат (или сертификат истёк — изготовитель не обновил вовремя).

2. Агент «Русского регистра» (или ОЙЛТИМ) запрашивает в КТМ паспорта, связанные с этим сертификатом, → DID приборов → текущие владельцы и места (склад / план / монтаж).

3. КТМ рассылает сигнал покупателю и изготовителю; агенты готовят перечень затронутых приборов с обоснованием; порядок замены — по договору, решение — человек.

Признак завершения: есть сигнал у выбранных приборов (не у всей истории).

C. «Новое распоряжение Росстандарта» (межагентная сцена)

1. Документ (неформализованный) поступает в КТМ; агент «Русского регистра» извлекает: типы СИ, основания, сроки допустимой эксплуатации, требования к замене.

2. Сопоставление с реестром: какие did:ru:device по паспортам и сертификатам подпадают, чьи они.

3. Межагентный опрос в мандатах: агенты владельцев — фактическое состояние и место; агенты изготовителей — варианты замены, сроки, сервис.

4. Сводный AnalysisCredential: перечни, сроки, обоснование логики, варианты замены, рекогносцировка, предупредительные мероприятия — каждый вклад подписан своим агентом.

5. Люди утверждают план своей ЭП; КТМ фиксирует в HLF и следит за сроками.

Что из этого уже в коде (ветка, 2026-10-16)

Коротко: доверительный слой стенда (кто есть кто, кто что подписал, кто за кого отвечает, что агенту можно, что записано) в основном готов — мы впереди постановки. Остаются: поиск затронутых паспортов и события (делаю), схема результата агента (делаю), чейнкод (в работе), интеграции с ИС сторон и ГОСТ.

Журнал изменений